The International Telecommunications Union (ITU, formerly the CCITT) and the International Organization for Standardization (ISO) have promulgated a series of joint recommendations to standardize a seven-layer Open Systems Interconnection (OSI) protocol model that permits the communication of application data between heterogeneous computers in a uniform manner. The seven layers comprise a physical layer, a data link layer, a network layer, a transport layer, a session layer, a presentation layer, and an application layer.
These recommendations include the specification of Abstract Syntax Notation One (ASN.1), a standardized notation for describing application layer data structures. (ASN.1 is documented in ISO 8824 .vertline. CCITT Rec. X.208, later revised in ISO 8824-1 and ITU-T Recs. X.680 through X.683.) ASN.1 provides a notation for specifying the syntax of information to be passed between two systems that communicate within the OSI model. The gist of ASN.1 is to define data structures in a machine-independent form to facilitate communication between computing systems that have different hardware platforms, different operating systems and different communications software. These data structures include definitions of "types" and "values", which describe various structural and functional attributes of the data.
One powerful feature One of the type definition in ASN.1 is the ability to define a variant type, one whose actual definition is not determined until runtime. The specification of the variant type is left open, and is constrained to be one of several alternatives to be selected at runtime according to a mapping of values onto types, indexed by some contextual value. This is accomplished in a predictable manner by specifying one component of a constructed type as a discriminator whose runtime value is used as a key to interpreting the variant component of the constructed type. In the 1990 version of ASN.1, the variant type was denoted by the notation ANY DEFINED BY. This allowed the variant type to express its dependence on the value of some other specified component, but did not provide complete information about how to map values of the discriminator onto the appropriate type information to finally resolve the variant type.
This problem was solved in the revised ASN.1 standard issued in 1994, which replaced the ANY DEFINED BY notation by categories of information objects, information object sets, and information object classes. The combination of these with new subtype constraint notations offered a complete and flexible method for specifying variant types, their relation to discriminators, and the resolution information.
More particularly, the 1994 version introduced the concept of an information object, a new entity used to associate a particular value (typically an OBJECT IDENTIFIER or INTEGER) with a type. A collection of such information objects is called an information object set, which is analogous to a table where each row is an information object. The structure of the table (the "schema" in this analogy) is defined by an information object class. Information object sets provide the means to decode open types by mapping the value of some known component in the PDU being decoded onto the type information needed to decode an "open" component. The contents of an information object set may be statically defined or dynamically provided (or a combination of both).
The solution to handling variant types in the theoretical notation in ASN.1 created a need for effectively modeling the notation in an actual programming language. The types and values in ASN.1 may be mapped straightforwardly onto classes and instances in an object-oriented programming language, such as C++; however, there was no obvious method for mapping information objects, object sets, and object classes of the abstract syntax onto an object-oriented language. This problem stood in the way of devising compilers that would automatically map or convert ASN.1 syntax into C++ or another object-oriented programming language.
This problem was complicated by the fact that the information object sets may be extended at runtime and often contain no predetermined type resolution information. Thus, not only is the resolution of a variant type postponed until runtime, but the definition of the type resolution information may also be negotiated at runtime. Moreover, the same type resolution information (i.e., the same information object set) may be negotiated differently in different communications contexts. At a minimum, only the structure of the type resolution information is predetermined.
Consequently, there is a need for a data structure and method for mapping variant type information onto an object-oriented programming language that: (1) uses a straightforward mapping from ASN.1 information object sets; (2) models the information object sets such their values may be examined and extended where applicable; (3) allows multiple instances of the same information object set to support different communication contexts in the same application while providing a type-safe interface for initializing and updating information object set instances; (4) provides an interface for passing a "context" to an encoder/decoder which identifies information object set instances; (5) avoids solutions that require runtime writeable global variables (thread safety); and (6) provides a method for dynamically extending the variant type resolution information on an "as needed" basis during the process of decoding.
There is no current data structure or method that satisfies the above requirements. In particular, none are able to the support multiple communications contexts that require more than one instance of the same information object set.